Skip to content

Expose data for custom boot image creation#535

Merged
Freax13 merged 2 commits intorust-osdev:mainfrom
Wasabi375:disk_image
Feb 24, 2026
Merged

Expose data for custom boot image creation#535
Freax13 merged 2 commits intorust-osdev:mainfrom
Wasabi375:disk_image

Conversation

@Wasabi375
Copy link
Contributor

Right now it is difficult to use this bootloader with more than just the basic disk-images create by this crate, e.g. it is currently not possible to create a boot-image with multiple partitions.

It can be achieved but that requires a somewhat complex build script that installs "bootloader-x86_64-uefi" or the bios variants and then creates the fat-partition by hand.

This change exposes some functionality of DiskImageBuilder to make some of those things easier.
The bootloader crate already has a buildscript that installs the necessary uefi/bios creates and extracts those files into byte arrays. Those are now public.
I also extracted the functionality to create a boot-able FAT-partition into it's own function and marked it as pub.

The goal of this PR is not to create a fully configurable system to add partitions to the boot image, but to expose the necessary data, for consumer of this crate to build their own partitioning scheme.

Copy link
Member

@Freax13 Freax13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!

Sorry for the delay.

I'm not too sure about this. AFAICT the newly exposed APIs are primarily meant for expert users who want to have more control over the disk images. I'd expect that such users are capable of creating FAT images themselves (and probably prefer to do so), so I'm not sure how much of a help the new functions are.

@Wasabi375
Copy link
Contributor Author

Tbh I can't really explain what I was thinking when I exposed the bios side as pub. I think I only did this to allow some kind of feature parity with uefi but I think you are right, that this just exposes a lot of internal implementation details. Unless someone really wants this as a feature for bios we should leave it private. We can always expose some kind of API in the future. I personally only care about the uefi version so I removed the bios implementation for now.

The uefi side is less of an issue as uefi is contained in a single binary as you pointed out.

Sorry for the delay

Yeah no worries. Sometimes life gets in the way and I don't think anyone has a right to your time. As you can see I got distracted by life myself so I totally understand 😉

Copy link
Member

@Freax13 Freax13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@Freax13 Freax13 enabled auto-merge February 24, 2026 17:12
@Freax13 Freax13 merged commit e567622 into rust-osdev:main Feb 24, 2026
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants